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METHOD AND SYSTEM FOR EXTRACTING MEDICAL INFORMATION FOR 
PRESENTATION TO MEDICAL PROVIDERS ON MOBILE TERMINALS 

BACKGROUND OF THE INVENTION 

5 Field of the Invention 

The present invention relates to a technique for accessing medical databases and 
delivering the content thereof to medical providers through a mobile terminal. 
Description of the Related Art 

Medical providers are notoriously resistant to change in their workplace. As a 

1 O result, thpy frequently t\n Tint wrapt npw twhnrtlrtfiy simply heraiKP. it is new and may he 

better. Medical providers often only accept change when they have to or when it truly 
does make their job demonstrably easier and/or faster. 

Conversely, a common complaint among many medical providers is the lack of 
access to infbnnation needed to treat patients effectively. Medical providers are kmth to 
1 5 travel to aiLinconvpniegtly located desk lop terminal or workstation only to spend twtror 
1tw» gguitg S.Jogging into the system, accessing a database, afiKBetfsfetfiy sifting 



through the medical records that may be contained therein in an attempt to find a bit of 
dcrircd miWatioti, c^A ^^1%^wo^c^ A* CI f IwX - j a* C*Cf 

Medical institutions, such as hospitals, may have a paper file with hard copies of 
20 the pertinent medical information, but again, this is cumbersome, antiquated, and not 
always orderly. As more hospitals move to electronic databases, even these outmoded 
records may be hard to come by. Thus, the two primary vehicles by which medical 
records may be accessed arc inadequate to help medical providers access the medical 
records where they are needed the most - by the patients' bedsides. 
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The present invention comprises providing medical providers with medical 
records in a mobile terminal so that the medical providers may access the medical records 
without being tied to a desktop workstation. An individual or a company, both herein 
referred to as a service provider, may be the moving force behind these activities. It is 
5 expected that the service provider will be a profit oriented business who also desires to 

sec the quality of earo to patiento improve by th© provision of the medical r&cord& to tiiQ 

medical providers. 

Initially, the service provider will have to acquire the medical records in a format 
that is amendable to presentation on the mobile terminals, A flow chart of this initial 

10 process is illustrated in Figure 1 . The service provider or a representative of the service 
provider, may contact the managers of the databases containing the medical records 
(block 1 0). It is expected that these managers maybe hospitals or companies to whom 
hospitals have outsourced the medical record maintenance responsibilities. R,g., Cerner 
and Shared Medical System, inventor* - flo inc*e companies actually manage tftc 

1 5 database or are they merely the software providers? 



Additionally, it is possible that medical providers who are not associated with a hospital 

(eg^ prartir^ group, a partn<*rchip, a snln practitioner, or the like) may have medical 
20 records amendable to incorporation and use in the present invention. Thus, the service 
provider may also contact such individuals or groups and the present invention is not 
restricted to hospitals per se. Inventors - do you want to include this group? \ \f 




used as desired, (inventors - are all these databases going to be HL7 certified? Is the 
database you create HL7 compatible?) QUI s> fVr*A IS AtMeft^ JA /STT iVn^S 

5 {also - do you have an exemplary print out of how the data is stored before / J 

transformation and then after tranrforimitfon?) X- WILL fi-ft"fft lAJ ~M\S Pfcs?. 

A*lb SMAIC IT, 
Either of the lasi two cases greatly simplifies the extraction and translation of the data 

ftom the original database to the new database created by the service provider. 

The purpose of the extraction and reformatting is to present the data of the 

10 medical records in a format that is acceptable for display on a mobile terminal To 
facilitate an explanation of the methodology of the present invention, what follows is a 
discussion of the hardware. The term mobile terminal is intended to be a broad ranging 
term and includes mobile phones, personal digital assistants (PDA), pagers, and the like. 
However, the present application will focus on two such devices, namely personal digital 

1 5 assistants (mobile terminal 50) such as that illustrated in Figure 2 and mobile phones 
(mobile terminal 100) such as that illustrated in Figure 4, Mobile terminal 50 may be a 
PALM PILOT® or the like and may comprise a display 52 and a plurality of buttons 54 
as is conventional. Display 52 may include a data field 56 comprising a patient's name 

field 58, a movement icon 60 and a plurality Af special icntis &1. As is onnventinnsl nn 

20 most personal digital assistants, display 52 may comprise some form of touch screen, 
accepting inputs by touching the display 52. Display 52 may further comprise a data 
entry field 64 used in conjunction with a stylus (not shown) as is conventional. In one 
embodiment, the display 52 comprises a color display with the icons and information 
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also sold by Ericsson. Other networks are also possible. Mobile terminals 100 may 
move around within the local system just like they move about in a normal cellular 
system. Note further that the local wireless system need not be connected to the PLMN 
162 if so desired. For example, for security reasons, it maybe desirable not tu allow 
5 access Lo the PLMN 1 62 and die PSTN 1 66. 

In addition U> muking normal phone cully, receiving pages, short message services 

and the like, the mobile terminals 100 may also selectively access the server 152 and 
secure therefrom a medical record formatted according to Ihe present invention. It should 
be appreciated that appropriate encryption technology may be used so as to preserve the 

10 privacy of the medical information. The medical record is then displayed on the display 
1 10 of the mobile tennmal 100, In particular, mobile terminal 100 communicates via 
antenna ] ] 2 to a nearby radio head 154 and accesses server 1 52 through the CRT 150. 
The server obligingly provides the requested information, which in turn is broadcast from 
ute radio neaa i >4 to the mo Due terminal i w tor display. Any updates entered by the 

1 5 medical provider are forwarded upon entry by the medical provider ro the server 1 52. 

Note that servers 70, 1 52 may communicate with the computer containing the 
vriginu]* unaltered database of medical records, providing updates thereto as needed or 
desired* Thus, these computers may be networked through a conventional approach, 
sftlft^ti vnly rrmnflrtad over a mnriftm or flu*, lilt ft a* ncrrirel or desirrii 

20 Inventors, if you have a particular architecture for any of the above please 

provide. I have endeavored to use two architecture* that make sense, but they are 

\j x w tl - s '*^ 



little more than educated stabs in the dark, \ 
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\K Mebns H 8 are illustrated in tabular form in Figure 6. Scroll icons or buttons 200 ^ 

v r PA y v 

act to move medical providers between different menus or allow different icons 1 1 8 to be < 
displayed in of icon section 1 1 6, These icons may be used in place of the need for 
buttons on the mobile terminal 50 or 100. 
5 Other possible icons include thermometer ioon 202 that shifts the medical 

provider to an information screen containing information relating lo the patient' :> vital 

statistics. This may be a free form data entry field to record daily events. Further, it is 
contemplated that the previous day's text is reproduced automatically for the next day 
with some indicia (such as an asterisk) that the text is reproduced. Thus, the medical 

10 provider does not have to re-enter duplicative data every day. 

Prescription icon 204 shifts the medical provider to an information screen 
containing information relating to the current medications that the patient is receiving. It 
maybe linked to software that checks for harmful drug interactions or the like, 
other labs icon 20f> shifts the medical provider to an information screen 

15 containing information relating to lab tests that may have been run tor the patient. This 
may be presented as a pop up list that lists lab results that can then be viewed by selecting 
from the list. These lab tests may not be the most co mmon sorts of tests, but are used 
with sufficient regularity to be included. The text of the pop up list is specifically made 

Wye enough so that the medical provider can select from the list with th«r fingiftr rarhf*r 

20 than having to use a stylus. 

Hotlist icon 208 shifts the medical provider to a customizable information screen. 
Medical providers can indicate which lab tests they desire to see most frequently. This 
may be related to their specialty area for example. Thus, when this button is tapped, the 
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medical provider is taken to the teste that provide him with the most information. For 
example, a cardiologist may want to know the results for three certain tests, whereas ail 
intestinal doctor may want to know the results of a different set of four tests, '['his icon 
allows the medical provider to program the mobile terminal 50 or 100 to show these 
desired test results. 

CDC icon 210 ahift^ the medical provider to an information screen containing 

information relating to test results from a very common set of tests known as CBC. 

Chem7 icon 2 12 shifts the medical provider to an information screen containing 
information related to test results from a very common set of tests known as Chem7. 

Bug icon 214 shifts the medical provider to an information screen containing 
information related to microbiology cultures, Tluis, results from cultures sent on the 
person are available. E.g., blood infection grew out df E. Coli. 



Allergies icon 216 shifts the medical provider to an information screen containing 
Information related to allergies for that particular patient, it may be linked to ttte 
information in the prescription screen to check for allergic reactions to proposed 
medication regimens. 

Other data fields include HD - the hospital day* derived from the date of 
admission on the hospital record; PD - post operative day; DX - diagnosis; OR - 
operative procedure the patient underwent; and HX - history. It is. enTitempl»terl that the 
PD button will cause a calendar to pop up and the medical provider may indicate the day 
on which an operation occurred. The DX field will allow Ihe entry of free form text so 
that the medical provider may indicate in their own words the patient's relevant 
diagnoses. Likewise, the OR field will allow the entry of free form text so that the 
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medical provider may indicate the nature of the surgery and any other relevant details. 
Similarly, the HX field allows the entry of free form text about the history of the patient. 

Not all of this information need to be stored in the hospital database with the 
unaltered medical records. Rather, it may stored simply in the central servers, 70, 152 
5 and accessed by the medical providers as needed or desired. 

The important thing about the icons is their ability to be ceon easily and 

manipulated easily. They are preferably large enough arid ergonomically designed so as 
to allow actuation without the need for a stylus, but rather may be actuated with a thumb 
or other finger. They are preferably multicolored and intuitive so that medical providers 
1 0 may at a glance know which ioons will take them to what information. The exact 

placement of the icons on a display is not critical, and may be customized to the medical 
provider so that the icons most commonly used appear on the main screens in a desired 
location. 

Srill oxher commands/! cons may be incorporated into the displays 32, 1 10. A 



i a i im i command cnaoies me mecucai provider to use uuraiw ucoiiuiiu_ui luw l 
information to an IrDA compatible printer. | T ^ r , c r\ ^jcV- 



PRTNT command enables the medical provider to use infrared beaming of the patient . . 
A "Hotlist/Patient" command allows the medical provider to indicate on the 

i 

preferred first screen after selecting a patient's name from a list <rfpatients.l This may be, 

for example, the hntliat test results, or a general defaulter**™ having HD, PD, *nH OR 

20 information. Other screens are also possible as needed or desired. 

A NOTE command is a totally freehand blank screen that allows the medical 
provider to draw notes, pictures, or the like as needed. This command in particular may 
be pwevered in a particular position on the display 52, 1 10 in every screen, such aa the 
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lower right hand comer. Notes may be erased with an ERASER button on the scribble _ 

«. THIS (STCfit^Vt*^ /AJ ITS 

' HosrUfcC'BviT state Ftnt £4ttf f-mawj /£./rvf(.<. 

A DETAILS command allows the medical provider to secure more details about a (c&H'p/tyfafy 
particular lab or test result. In particular, it is expected that many lab or test results will / CcNV^ 1 / 
5 be abbreviated with the most commonly desired information presented first. Additional 

details will be available through the us© of ihis command. f,v*^CLth'lAC Tl*{. «#S« »n£ mifc-o \c>7l/ . t 

An ADD PATIENT command may be displayed os a sign ot the Tike. aa& 
allows the medical provider to enter a patient's medical record number^namially, and at 
the next synchronization, the patient's complete medical record will be loaded into the 

1 0 memory of the mobile terminal 50, 1 00. In the situation where the mobile terminal is a 
mobile type device, this command will activate a call to the central server 152 and 
download the information. This feature allows medical providers to acquire access to the 
medical records of patients that were erroneously omitted from a synchronization or 
added to the ward after a synchronization visit 

1 5 Other features arc also possible. For example, as an alternate revenue generator, 

the service provider could sell advertising on a ^iRi^of the Day" icon* This might be 
located in an unobtrusive portion of the display 1 1 0 so as to avoid inadvertent triggering. 
Medical providers may peruse this feature in down time, such as when waiting on an 

ftlpvnrnr, mating a m*?»l, or the like. Tbis may pliminntft nee4l?94 interruptions by sale* 

20 representatives or the like. Further, in one embodiment of the present invention, when 
medical providers subscribe to the present service, they would identify their specialty 
areas and qualifications. This may be done to differentiate between medical sludents and 
attending physicians, nurses, and the like. With the identification of the specialty areas, 
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"Wit SMflW'te iM , . 
of P<« 5 TC ShCTW ^ . 1 , <, 

the advertising tnay be targeted specifically to the desired audience, For example, ^ ft- 1/ S fil < i. 
cholesterol drugs could be advertised to cardio-thoracic surgeons while VIAGRA™ was > 

advertised to a geriatric specialist^ 

ft 

Similarly, as a security measure, if the mobile terminal 50, 1 00 is not used for an 
5 amount of time greater than a predetermined threshold, the medical provider may have to 
log in to the device Thia may done through any well understood usur nuznc and 

password type log in activity. Further, if the mobile terminal 50, 1 00 is not used for an 
amount of time greater than a second predetermined threshold, the entire memory of the 
mobile terminal 50, 100 may be purged of all medical records. This helps itteure that 

10 access to the confidential medical information is not given to an unauthorized user. 

As vet another concern, the Health Insurance Portability Account Act (HIPAA) of 
1997 has laid out several federal rules about electronic data transfer as it relates to 
medical records. Individuals or companies who practice the present invention need to be 
aware of the contemporaneous interpretation of this statute to comply therewith. 

1 5 Against this backdrop of hardware and software, the methodology of promoting 

the service is presented with reference to Figure 7. Initially, the service provider 
establishes the database with the information formatted in the appropriate manner (block 
200). This process was described with reference to Figure 1 > The service provider may 
distribute for fre* mobile terminal* (either personal digital aeeictante, mnhite phone*, «r 

20 other appropriate device) to a select number of medical providers, for example, the first 
1 ,000 medical providers (block 202). At the same time, the service provider could 
require service contract commitments from the medical providers that have just received 
a new mobile terminal (block 204). The service contract allows access to the reformatted 
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It/Of & ^rUN^U Sii-SlSSW&tf TC 

(j.c. !*'5, ^ 5,C*S* HcC's .M«tf S^^rs, 
desiied. Thes^additional services may be add-ons to the basic service package, resulting 
in additional ite venue for the service provider, or packaged together as needed or desired. 

Exemplary methods of using the present invention by medical providers are 
presented in Figures 8 and 9 as flow charts. These are exemplary and not intended to be 
5 limiting, but are provided to illustrate how the present invention may be used by a 

mvdicul providvr tb mako hi a life easier. Figure 8 acBumeD that tk$ medical prouder has 

a personal digitetfesistmf^pe mobile terminal 50- In particular, the medical provider is 
assumed to ba a physician. TJbe physician initially secures a mobile terminal 50 and a 
service contracv^bioelr?(5o). This may be the result of an advertising promotion, word of 

10 mouth advertising, or other reason. At some later point, the physician has begun using 
the personal digital assistant as a calendar and the like. The physician wakes up (block 
302) and as part of his morning ritual, checks his calendar on the mobile terminal 50 
(block 304} to see the day's appointments. Note that this calendar software is 
conventional on most personal digital assistants and is not Incorporated Into the suftwme 

15 of the present invention. Both applications reside concurrently in memory on the mobile 
terminal 50. This maybe in the midst of breakfast, between shaving and showering, or 
whenever is convenient 

The physician then goes to the hospital (block 306). One of the fir&t things that 
the physician does is to dock his mobile terminal 50 at a docking station 76 to download 

20 all the needed medical records to the mobile terminal 50 (block 308). Note that the 

physician may only get medical records for his patients, the patients on the ward in which 
the physician works, or some other subset of all available medical records. This 
preserves memory in the mobile terminal 50 if desired. Some physicians may restrict 
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occur. Medical providers may dock more often than indicated it desired, or less 
frequently if desired. Further, updates may have to be entered through other means rather 
lhan through the mobile terminals 50 and 100. The flow charts are to illustrate exemplary 
embodiments. 

Inventors, I would like to attach the code that you have written for both the 

reformatting and thte application ao an appendix to the application Avmri any 

enablement issues. We can claim copyright in the code, but It will prove that we 

have the invention in hand. 

The present invention may, of course, be carried out in other specific ways than 
those herein set forth without departing from the scope and the essential characteristics of 
the invention. The present embodiments are therefore to be construed in all aspects as 
illustrative and nol restrictive and all changes coming within the meaning and 
equivalency range of the appended claims are intended to be embraced therein. 
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CLAIMS 

What is claimed is: 

L A method of presenting medical records for use by a medical provider, comprising: 
extracting pre-existing medical records from a database; 
formatting said medical records for presentation on a mobile terminal; and 

delivering at ono unid formatted modionl rooordo to a mobile terminal 

possessed by a medical provider. 

2. The method of claim 1 wherein formatting said medical records for presentation on a 
mobile terminal comprises providing ergonomic actuators within said medical records to 
move between different screens containing different information, 

3. The method of claim 1 wherein delivering at least one of said formatted medical 
records to the rnobi le terminal possessed by the medical provider comprises delivering ai 
least one of said medical records to a wireless telephone. 

4. The method of claim 1 wherein delivering at least one of said formatted medical 
Tecords to Ihe mobile terminal possessed by the medical provider comprises delivering at 

least one of said medical trpmrds tn a pprsnnal digital Assistant 

5. The method of claim i wherein extracting pre-existing medical records from a 
database comprises extracting pre-existing medical records from a hospital database. 
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INTRODUCTION 



The purpose of this document is to provide a technical overview of MercuryMD's clinical data 
distribution system. Our product vertically integrates patient care databases to handheld devices 
of individual medical practitioners (MD, PA, RN, etc) through a user-friendly interface that 
increases efficiency, reduces errors, and improves patient care. 

LOGICAL ARCHITECTURE 

MInterface. MercuryMD's data distribution system does not replace existing legacy systems at 
any individual medical center. Indeed, most institutions have invested in a variety of systems 
from multiple vendors that serve needs such as ADT, laboratory data retrieval, radiology, 
dictation storage, and pharmacy. We provide a modular interface, MInterface, that sits aside 
these individual systems and assimilates information into our central database. MInterface is an 
ActiveX EXE built in Microsoft Visual Basic 6.0 that runs on our Windows 2000-based server. 
It is a database-driven service that relies on institution- or system-specific metadata to interpret 
coded data and insert it into our central database. 

Typically, our system is provided user access by the host systems for secure authentication. All 
transactions between MInterface and external systems are logged in MCentral (see below). 
MInterface can be configured to function in a variety of modes: it can poll existing systems at 
regular time intervals, poll existing systems based on the knowledge that new data is available, 
or it can monitor a message stream and generate events to update our central database as 
necessary. Configuration of MInterface is performed by MercuryMD's implementation 
consultants in collaboration with technical personnel and vendors at each institution. 

MCentral. Our relational database, MCentral, performs four tasks: 1) Maintain archive of 
clinical data on active patients; 2) Maintain knowledge of the state of all data on each user's 
handheld device; 3) Support user collaboration in patient care by supporting multi-user Teams 
that share patient data; and 4) Support the database-driven aspects of MInterface and MConduit. 
MCentral is currently implemented in Oracle 8i, however, the tables and views have been 
designed with portability in mind so that the database can be implemented in any enterprise- 
capable relational DBMS that is already supported and/or licensed by the institution. 

MCentral's entity-relationship diagram is proprietary. However, MIS personnel at our 
institutional partners have read-only access to MCentral's data and structure subject to terms of 
our non-disclosure agreement. Such access will allow institutions to eventually integrate billing 
and diagnosis data collected by caregivers at the point of care. Access to MCentral is limited to 
that granted to our internal MInterface and MConduit systems and read-only access provided to 
authorized institutional administrators. 

It is important to emphasize that MCentral is not a data repository. Patient data has a limited 
lifetime within our database, which implies that our database will asymptotically approach a 
maximum size dictated by the number of hospitalized patients. The lifetime of patient data is 
typically from 72 hours before the current hospital admission until 72 hours after discharge. For 
liability reasons, we do not currently replace any institutional data collection or archival systems. 
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While our user interface supports diagnostic coding and charge capture for inpatient services, 
this functionality is currently only in evaluation and not for permanent storage or institutional 
use. 

MConduit. Our conduit technology has been licensed from Extended Systems 
(www, ext endedsvstems . com) in the form of their XTNDConnect Server software. This software 
is a robust, scalable handheld device management platform that provides high-level 
synchronization design for multiple platforms. Additionally, it provides robust user management 
and security services for both database access and end-user synchronization. MConduit provides 
concurrent multi-user handheld synchronization services over any access modality (wired 
cradles, infrared, RF networks) that supports TCP-IP. This flexibility eliminates the requirements 
for workstation-driven synchronization software and reduces the cost of large-scale distribution. 

MConduit and its integration with MCentral provide considerable speed advantages during 
synchronization. Since MCentral contains knowledge of the information state on each user's 
device, we only transfer changes between handheld and server during synchronization. So-called 
"delta synchronization" reduces synchronization time and is more efficient for server and 1 
network. 

Data encryption during synchronization is not generally required if synchronization occurs 
within the confines of the institutional Intranet. However, if the institution desires to support 
Internet-based synchronization allowing users to connect from home using XTNDConnect's 
Proxy software, XTNDConnect provides 128-bit Certicom encryption for financial-grade data 
security. 

MConduit is essential to our system's overall security model. It provides both device- and user- 
level authentication during synchronization and allows us to manage users internally or through 
existing Microsoft Exchange or Lotus Notes directory servers. Most importantly, MCentral 
controls all database connections with MCentral and eliminates the need for database-level user 
authentication. 

MData. MData is our flagship program that runs on handheld devices running Palm OS 
3.0 or greater. It is a C application that provides rapid data retrieval with a unique interface 
optimized for stylus-free use. 

The most striking feature of MData besides its overall look and feel is the inherent support for 
team-based patient care. Users can aggregate into teams in the MCentral database, and all team 
members share rounding, diagnosis, allergy, and history information as entered by any 
individual. During synchronization, any users with the latest version of editable data are allowed 
to forward their changes to the server for subsequent sharing with other team members. In the 
event that the server data has changed underneath a user who has also made changes before 
synchronizing, a conflict resolution system alerts the user and allows him/her to choose between 
resubmitting the changes during the next synchronization or canceling the changes and accepting 
the latest data from the server. 
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MData also contains a number of additional features deemed essential by practicing residents 
and private practitioners: instant access to all the latest laboratory data, a patient-specific sketch 
field for freeform notes, automatic carry-forward of the previous day's notes to speed 
documentation, and an intuitive interface to support diagnosis and charge capture within the 
workflow of data retrieval and clinical decision making. 

MData's Palm databases are automatically updated by the MConduit system during each 
synchronization. MData's Palm databases are packed in a binary format on the handheld, and 
unpacking these data requires a priori knowledge of our underlying table structure. We also 
prevent our databases from being copied to users' desktop computers during routine HotSync 
operations and prevent infrared transfer of our databases between devices. 

A unique user login and a user-specified PIN of at least 4 numbers provide security for the 
MData application. The valid login must be entered at initial startup and must be present at each 
synchronization. Given user's needs to rapidly navigate between applications on their handheld 
device, we do not require PIN entry each time MData is launched. Instead, the user is required to 
enter his/her PIN if it has been at least 60 minutes since the last authentication. 

PHYSICAL ARCHITECTURE 

Server. The server provided by MercuryMD is a Dell PowerEdge 2400 server with two 
600MHz Pentium HI processors and a three-drive 18-gigabyte RAID 5 array. The server runs 
Microsoft Windows 2000 and runs Oracle 8i for the MCentral database, our XTNDConnect 
MCentral conduit, and the MInterface application. It requires a fixed IP address either through 
direct network configuration or assignment of a fixed IP from a DHCP server through its NIC 
identifier. We also provide Norton PCAnywhere 9.2 for remote access and troubleshooting. 

The server can either be physically located on the institution's backbone for maximum 
performance or it can reside in the MercuryMD server farm for access over the Internet. The NIC 
supports 100 megabit per second Ethernet connectivity. 

Synchronization Stations. Synchronization services are currently provided using Clarinet 
hubs and IRDA transceivers (www.clarinetsvs.com) for wireless and cradle-free access. Each 
Synchronization Station consists of one Clarinet hub and seven IRDA transceivers arranged in a 
custom-designed box that holds the user's Palm devices during the synchronization process. The 
box itself takes up one by two feet of desk or table space and can support further storage (paper 
forms, supplies, etc.) on top of it. The station requires only one 120- volt wall outlet and orie 
Ethernet connection for the hub. 

The IRDA hub connects into the network and can either be manually assigned an IP address or 
automatically assigned an address from a DHCP server. The hub can also assign IP addresses to 
the IRDA transceivers manually or obtain IP addresses for each transceiver from a DHCP server. 
Configuration of the hub needs to occur only once, with specifications stored in non- volatile 
RAM before placement in the appropriate location. 
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